workflows: use cachix consistently#435294
Conversation
nix-owners
bot
requested review from
MattSturgeon,
Mic92,
philiptaron and
zowoq
nixpkgs-ci
bot
added
10.rebuild-darwin: 0
MattSturgeon
left a comment
MattSturgeon
left a comment
There was a problem hiding this comment.
Seems good, can't see any issues.
nixpkgs-ci
bot
added
2.status: merge conflict
wolfgangwalther
force-pushed
the
ci-cachix
branch
2 times, most recently
from
d2a1e83 to
d450d03
Compare
|
Resolved conflicts after the codeowner merge. |
philiptaron
left a comment
philiptaron
left a comment
There was a problem hiding this comment.
Couple questions about the parameters. This looks great.
.github/workflows/codeowners-v2.yml
Outdated
There was a problem hiding this comment.
No tarball restriction here
There was a problem hiding this comment.
Yeah, the tarball is only built in the build job.
There was a problem hiding this comment.
I'm definitely not looking for a solution or change here in this PR, but it would be amazing to fork this action for our purposes, so that we could invent a declarative syntax here instead of concatenating and copy-and-pasting regular expressions.
I also have a mild preference for the scheme used in the so-called "Magic Nix Cache" where the GitHub actions cache is used.
There was a problem hiding this comment.
I also have a mild preference for the scheme used in the so-called "Magic Nix Cache" where the GitHub actions cache is used.
Thought about this a little bit.. the downside of anything based on GHA cache is, that these caches are always branch specific with the exception of the default branch. The default branch's cache is available everywhere. But that means we actually need to run all these things that we currently run only in PRs also on push events.
We will want to run these things on the merge queue, but once we do we certainly don't want to double the resources to run them on push as well. So I think that kind of cache is not going to work well for us, especially considering that stable branches will not be considered "default" in the sense of that anyway.
nixpkgs-ci
bot
removed
the
2.status: merge conflict
This allows setting up a custom cachix cache in a contributor's fork. That's most valuable when working on CI itself, testing and interating in a fork. It's required when working on cachix related features directly.
Pushing the source path to cachix is pointless, because the only source we're using is Nixpkgs - and that will always be available already via checkout. No need to ever substitute it, so no need to push it either.
For PRs targeting a fast moving branch like master, it might not actually help because the merge commit will still be different on each run. But on slower moving branches or when testing in a fork, it can speed things up. Since each of these build results is only a few hundred bytes without any dependencies, it has essentially no cost. Not adding this to `treefmt`, because this looks at *all* the files in the repo, so needs to re-run even when iterating on CI only.
Speeds up evaluation a bit, because `filtered head` doesn't need to be evaluated 3x.
nixpkgs-vet doesn't care about our CI infrastructure, so ignoring these files will lead to more cache hits when iterating on CI related PRs.
At this stage, this only allows faster iteration when working on CI in forks.
By definition the tarball changes on every commit, so it makes no sense to cache it - it will just waste disk space.
wolfgangwalther
force-pushed
the
ci-cachix
branch
from
d450d03 to
ac93865
Compare
|
Successfully created backport PR for |
github-actions
bot
added
the
8.has: port to stable
3 participants
This uses the
nixpkgs-cicachix cache in most of the CI jobs. This mostly has an effect when iterating on CI in a fork, where the target branch (and thus the merge commit) is not moving at all. It can also have a benefit when pushing to PRs targeting slower moving branches (release branches or even stable staging, which doesn't receive many commits at all). If lucky, you might also benefit from this caching if fixing a commit message or squashing commits immediately after CI has run on your PR and the target branch hasn't advanced, yet.It also allows setting up a cachix cache in a fork, which is important to be able to test changes related to that. I am currently doing that, trying to replace some of the artifact download stuff for Eval with cachix instead (not part of this PR).
This should also make the nixpkgs-vet job a few seconds faster in general.
Things done
Add a 👍 reaction to pull requests you find important.